This chapter describes how to use the Point-to-Point Protocol for interfaces on the device. Sections in this chapter include:
See "Using the Multilink PPP Protocol" and "Configuring and Monitoring Multilink PPP Protocol (MP)" for information about using the Multilink PPP Protocol.
PPP provides a method for transmitting protocol datagrams at the Data Link Layer over serial point-to-point links. PPP provides the following services:
Figure 22. Examples of Point-to-Point Links
PPP currently supports the following control protocols:
Each end starts by sending LCP packets to configure and test the data link. After the link has been established, PPP sends NCP packets to choose and configure one or more network layer protocols. After network layer protocols have been configured, datagrams from each network layer can be sent over the link. The next sections explain these concepts in more detail.
PPP transmits data frames that have the same structure as High-level Data Link Control (HDLC) frames. PPP uses a byte-oriented transmission method with a single-frame format for all data and control exchanges. Figure 23 illustrates the PPP frame structure and is followed by a detailed description of each field.
Figure 23. PPP Frame Structure
*------*---------*---------*----------*-------------*--------*-------* |Flag | Address | Control | Protocol | Information | FCS | Flag | *------*---------*---------*----------*-------------*--------*-------* 8 bits 8 bits 8 bits 16 bits variable 16 bits 8 bits
Protocol field values in the range '0xC000'-'0xFFFF' indicate Layer 3 data (protocol datagrams) such as LCP, PAP, CHAP,
When the protocol type is LCP, exactly one LCP packet is encapsulated in the information field of PPP Data Link Layer frames.
PPP links can negotiate the use of various options which may modify the basic frame format; the description below applies to the frame format prior to any such modifications. PPP LCP packets are always sent in this format as well, regardless of negotiated options, so that LCP packets can be recognized even when there is a loss of synchronization on the line.
The router supports two such options: Address and Control Field Compression (ACFC) and Protocol Field Compression (PFC). These are described in detail in a later section.
PPP's Link Control Protocol (LCP) establishes, configures, maintains, and terminates the point-to-point link. This process is carried out in four phases:
If this negotiation is unsuccessful, the link is considered to be "down" and incapable of carrying any network traffic. If the negotiation is successful, LCP goes to an "Open" state and PPP goes on to the next phase.
If authentication fails, the link is marked "down" and cannot carry any network traffic. If authentication succeeds or if authentication is not required, the PPP link moves to the next phase.
Each layer-3 protocol is negotiated independently. When a particular NCP successfully negotiates, the link is "up" for that protocol's traffic. As with LCP, configuration information can be exchanged as part of this negotiation; for example, IPCP can exchange IP addresses or negotiate the use of "Van Jacobson IP header compression".
As with LCP, it is possible for an NCP to fail to negotiate successfully with its peer. This might happen because the peer does not support a particular protocol or because some configuration option was unacceptable. If an NCP fails to reach the "Open" state, no layer-3 protocol packets can be exchanged for that protocol even though other layer-3 protocols are successfully passing traffic across the PPP link.
For complete details about PPP LCP, authentication, and the general NCP negotiation mechanisms, consult RFCs 1331, 1334, 1570, and 1661.
LCP packets are used to establish and manage a PPP link and can be loosely divided into three categories:
Exactly one LCP packet is encapsulated in the information field of PPP Data Link Layer frames. In the case of LCP packets, the protocol field reads "Link Control Protocol" (C021 hexadecimal). Figure 24 illustrates the structure of the LCP packet and is followed by a detailed description of each field.
Figure 24. LCP Frame Structure (in PPP Information Field)
*-----*------------*--------*-------------* |Code | Identifier | Length | Data(option)| *-----*------------*--------*-------------*
| Code | Packet Type |
|---|---|
| 1 | Configure-Request (Link Establishment) |
| 2 | Configure-Ack (Link Establishment) |
| 3 | Configure-Nak (Link Establishment) |
| 4 | Configure-Reject (Link Establishment) |
| 5 | Terminate-Request (Link Termination) |
| 6 | Terminate-Ack (Link Termination) |
| 7 | Code-Reject (Link Establishment) |
| 8 | Protocol-Reject (Link Establishment) |
| 9 | Echo-Request (Link Maintenance) |
| 10 | Echo-Reply (Link Maintenance) |
| 11 | Discard-Request (Link Maintenance) |
NCP packets are structured identically to LCP packets and are distinguished by having different PPP "Protocol" values. Each LCP packet type (distinguished by the code field) has the same meaning for each NCP, though an individual NCP may not implement all possible LCP packet types. NCPs normally implement all of the link establishment type packets that LCP defines. They may implement some of the additional LCP packet types, and they also may define additional packet types beyond what LCP uses. Unlike LCP packets, the structure of an NCP frame may be modified according to options negotiated by LCP during the link establishment phase.
Link Establishment Packets establish and configure a point-to-point link including the following packet types:
Both ends send Configure-Request and both ends must receive a Configure-Ack before the link opens. Options negotiated for one direction may differ from that negotiated for the other direction. There is no "master-slave" relationship. Rather, each end works symmetrically.
When the originator receives a Configure-Nak packet, a new Configure-Request packet is sent that includes modified, acceptable configuration options.
When the originator receives a Configure-Reject packet, a new Configure-Request packet is sent that does not include any of the configuration options received in the Configure-Reject packet.
| Note: | NCP packet types and structure are the same as LCP, although there are a few additional "code" fields associated with some NCPs. |
Link Termination Packets terminate a link and include the following packet types:
Link Maintenance Packets manage and debug a link, and include the following packet types:
PPP authentication protocols provide a form of security between two nodes connected via a PPP link. If authentication is required on a box, then immediately after the two boxes successfully negotiate the use of the link at the LCP layer (LCP packets are exchanged until LCP goes into an "open" state), they go into an "authentication" phase where they exchange authentication packets. A box is neither able to carry network data packets nor negotiate the use of a network protocol (NCP traffic) until authentication negotiation completes successfully.
There are different authentication protocols in use: Password Authentication Protocol (PAP) and Challenge/Handshake Authentication Protocol (CHAP). Microsoft PPP CHAP (MS-CHAP) is also available to authenticate Windows workstations and peer routers. PAP and CHAP are described in detail in RFC 1334, and briefly described later in this section. MS-CHAP is described in RFC 1994.
On remote dial-in access ports, a third authentication protocol is available. This is Shiva Password Authentication Protocol (SPAP), which is a Shiva proprietary protocol. See "Shiva Password Authentication Protocol (SPAP)" for more information.
Whether a box requires the other end to authenticate itself (and if so, with what protocol) is determined during the LCP negotiation phase. Authentication could be considered to "fail" even at the link establishment phase (LCP negotiation), if one end does not know how, or refuses to use, the authentication protocol the other end requires.
Each end of a link sets its own requirements for how it wants the other end to authenticate itself. For example, given two routers "A" and "B", connected over a PPP link, side A may require that B authenticate itself to A using PAP, and side B may require that A similarly identify itself using CHAP. It is valid for one end to require authentication while the other end requires none.
In addition to initial authentication during link establishment, with some protocols an authenticator may demand that the peer reestablish its credentials periodically. With CHAP, for example, a rechallenge may be issued at any time by the authenticator and the peer must successfully reply - or lose the link.
If more than one authentication protocol is enabled on a link, the router initially attempts to use them in the following priority order:
| Note: | SPAP is only available on interfaces that have IBM DIALs Dial-In circuits configured. |
If the remote side responds to the authentication request with NAK and suggests an alternative, the router uses the alternative, provided that it is enabled on the link. If the remote side continues responding to the router's suggestions with NAK but does not provide an alternative that the router has enabled, the link is terminated.
The Password Authentication Protocol (PAP) provides a simple method for the peer to establish its identity using a two-way handshake. This is done only upon initial link establishment. Following link establishment, the peer sends an ID/Password pair to the authenticator until authentication is acknowledged or the connection is terminated. Passwords are sent over the circuit "in the clear," and there is no protection from playback or repeated trial and error attacks. The peer controls the frequency and timing of the attempts.
The Challenge-Handshake Authentication Protocol (CHAP) is used to periodically verify the identity of the peer using a three-way handshake. This is done upon initial link establishment, and may be repeated anytime after the link has been established. After the initial link establishment, the authenticator sends a "challenge" message to the peer. The peer responds with a value calculated using a "one-way hash" function. The authenticator checks the response against its own calculation of the expected hash value. If the values match, the authentication is acknowledged; otherwise the connection is terminated.
MS-CHAP is an extension to PPP CHAP that is used to authenticate remote Windows workstations and peer routers. Both MS-CHAP and CHAP use PPP's Link Control Protocol (LCP) to negotiate the desired authentication protocol in one or both directions; both use the CHAP protocol identifier as the PPP protocol; and each protocol uses a random challenge which is encrypted as part of the response.
MS-CHAP can be used with the internal PPP user Local List database, but not with the external AAA authentication server that is described in the chapter "Using Local or Remote Authentication" in Using and Configuring Features. If you plan to use Microsoft PPP Encryption (MPPE) on a PPP interface, you must enable MS-CHAP on that interface before you configure MPPE. Use the talk 6 command enable mschap to enable MS-CHAP.
| Note: | SPAP is only available on interfaces that have IBM DIALs Dial-In circuits configured. |
The Shiva Password Authentication Protocol (SPAP) provides a simple method for the peer to establish its identity using a 2-way handshake similar to PAP. After the Link Establishment phase is complete, an Id/Password is repeatedly sent by the peer to the authenticator until authentication is acknowledged, the connection is terminated, or a retry counter expires.
SPAP is a moderately strong authentication protocol that uses a proprietary encryption algorithm for the password. In addition to authentication, SPAP offers:
The following sections describe configuring PPP authentications for two situations:
These two situations are independent. You can do one or the other.
To authenticate a remote device or dial-in client:
You can use any of the following protocols:
| Note: | MS-CHAP can use the PPP local database to authenticate, but cannot use an authentication server. |
| Note: | SPAP is only available on interfaces that have IBM DIALs Dial-In circuits configured. |
At the Config> prompt, use the add ppp_user command. See "Add" for more information.
A 2212 maintains a single PPP user database. When the remote router or device sends its name and password to the device during the authentication phase, the device checks to see if that name and password are in the PPP user database.
To configure the device to be authenticated by a remote device or dial-in client, configure the device's name and password:
| Attention: | Do not use the following commands unless you want the device to perform authentication as described in "Using Local or Remote Authentication" in Using and Configuring Features . |
| Note: | SPAP is only available on interfaces that have IBM DIALs Dial-In circuits configured. |
Callback is a PPP feature associated with single user dial-in solutions. It attempts to accomplish two objectives. These objectives are:
Callback is supported only on dial-in dial circuits over V.34 or ISDN networks.
Config>add PPP Enter user name: [ ]? nocallback Password: Enter password again: Is this a Single-User or a Network? (Single-User, Network): [Single-User] IP address for user nocallback [0.0.0.0]? Enter HostName: [ ]? Give 'nocallback' default time allotted ? (Yes, No): [Yes] Enable Callback for 'nocallback' ? (Yes, No): [No] yes Type of Callback (Roaming Callback, Required Callback): [Roaming Callback] Requ Dialback number for this user [ ]? 555-1234 Will 'nocallback' be able to dial-out ? (Yes, No): [No] PPP User Name: nocallback Type: Single User User IP Address: Interface Default SubNetMask: 255.255.255.255 Hostname: <undefined> Time-Alotted: Box Default Call-Back Type: Required Callback Phone Number: 543-3186 Dial-Out: Not Enabled Encryption: Not Enabled Is information correct? (Yes, No, Quit): [No] yes
Config>add PPP Enter user name: [ ]? sallydoe Password: Enter password again: Is this a Single-User or a Network? (Single-User, Network): [Single-User] IP address for user nocallback [0.0.0.0]? Enter HostName: [ ]? Give 'no callback' default time allotted ? (Yes, No): [Yes] Enable Callback for 'no callback' ? (Yes, No): [No] Will 'no callback' be able to dial-out ? (Yes, No): [No] PPP User Name: no callback Type: Single User User IP Address: Interface Default SubNetMask: 255.255.255.255 Hostname: <undefined> Time-Alotted: Box Default Call-Back Type: Not Enabled Dial-Out: Not Enabled Encryption: Not Enabled Is information correct? (Yes, No, Quit): [No] yes
Config>add PPP roaming_callback Password: Enter password again: Is this a Single-User or a Network? (Single-User, Network): [Single-User] IP address for user roaming_callback [0.0.0.0]? Enter HostName: []? Give 'roaming_callback' default time allotted ? (Yes, No): [Yes] Enable Callback for 'roaming_callback' ? (Yes, No): [No] yes Type of Callback (Roaming Callback, Required Callback): [Roaming Callback] Will 'roaming_callback' be able to dial-out ? (Yes, No): [No]n PPP User Name: roaming_callback Type: Single User User IP Address: Interface Default SubNetMask: 255.255.255.255 Hostname: <undefined> Time-Alotted: Box Default Call-Back Type: Roaming Callback Dial-Out: Not Enabled Encryption: Not Enabled Is information correct? (Yes, No, Quit): [No]yes
See "Using Local or Remote Authentication" and "Configuring Authentication" in Using and Configuring Features for this information.
PPP has a family of Network Control Protocols (NCPs) for establishing and configuring different network layer protocols. The NCPs are responsible for configuring, enabling, and disabling the network layer protocols on both ends of the point-to-point link. NCP packets cannot be exchanged until LCP has opened the connection and the link reaches the OPEN state.
PPP supports the following Network Control Protocols:
ATCP is specified in Request for Comments (RFC) 1378. IBM's implementation of ATCP supports the AppleTalk-Address option. The implementation supports both full router mode and half router mode. For additional information, refer to "AppleTalk over PPP" in Protocol Configuration and Monitoring Reference Volume 2.
RFC 1763 describes BVCP. IBM's implementation of BVCP does not support any options.
BCP is specified in RFC 1638. IBM's implementation of BCP supports the IEEE 802.5 Line Identification Option and the Tinygram Compression Option.
NetBIOS Control Protocol (NBCP) is a proprietary NCP developed by Shiva Corporation and used by the IBM Dial In Access to LAN Client for OS/2, DOS and Windows for single-user dial-in. NBCP is used to transport NetBIOS and LLC/802.2 bridged traffic from these clients, dialed into a 2212 DIALs Server, onto an attached LAN. IBM's implementation of NBCP supports the MAC-Address and NetBIOS Name Projection options.
NetBIOS Frame Control Protocol (NBFCP) is specified in RFC 2097. NBFCP is used by Microsoft Windows 95 and Windows NT Dial-Up Networking clients for single-user dial-in. NBFCP is used to transport NetBIOS bridged traffic from these clients, dialed into a 2212 DIALs Server, onto an attached LAN. IBM's implementation of NBFCP supports the Name-Projection, Peer-Information and IEEE-MAC-Address-Required options.
| Note: | CBCP is only available on interfaces that have IBM DIALs Dial-in circuits configured. |
Callback Control Protocol (CBCP) is used by Microsoft Dial-Up Networking clients to negotiate callback. The 2212 supports callback to a single user-specified number (roaming callback) and callback to an administrator-specified number (required callback). The CBCP option of calling a list of numbers is not supported.
PPP users that want to use CBCP callback must have some form of authentication enabled (like PAP, CHAP, SPAP or MS-CHAP). There are no configuration parameters for CBCP. (The client determines when it is used.) See Configuring PPP Callback for information about configuring PPP users for callback.
DNCP is specified in RFC 1762. IBM's implementation does not support any DNCP options.
IPCP is specified in RFC 1332. IBM's implementation supports the following options:
An IP address can be requested for this interface. If Dynamic-Address is enabled in the IP configuration for this interface, the peer will supply the address each time the connection is established.
The router can send its IP address, as well as accept an IP address, from a peer, or supply an IP address to a peer, if requested. If the router is configured to "Send Our Address" on a particular interface, and that interface has a valid, numbered IP address, then IPCP sends the address in its initial Configure-Request as option 3 (IP Address). IPCP also sends its address if the peer sends a Configure NAK with 0.0.0.0 for option 3 (IP Address), if a valid numbered address is configured for that PPP interface. IPCP will not send an unnumbered address to its peer.
A peer may specify its address (referred to as "Client Specified"), or request an address from the router by sending 0.0.0.0 for Option 3 in its initial Configure Request. The router may obtain this address from the authenticated user profile or from the interface itself. The user profile address takes precedence over the interface address. If you do not want to offer an address from the user profile, simply leave the address for that user in the profile as 0.0.0.0, and the router will offer the remote address configured for that interface. If there is no remote address configured for the interface or user profile, and the peer continues to request an address, IPCP will fail.
The router automatically adds a static route directed to the PPP interface for the address that is successfully negotiated, allowing data to be routed properly to the dial-in client. When the IPCP connection is ended for any reason, this static route is subsequently removed. By default, the net mask for this route is 255.255.255.255 (hostroute); however, if a net mask is specified in the authenticated user's profile (see "Configuring PPP Authentication") a net mask other than this may be used to allow routing to more than a single host across the PPP link (RIP or other routing protocols could also be used to discover routes if desired).
IPv6 Control Protocol is specified in RFC 2023. In IBM's implementation of IPv6CP, the router can send its IP address, as well as accept an IP address, from a peer, or supply an IP address to a peer, if requested. If the router is configured to "Send Our Address" on a particular interface, and that interface has a valid, numbered IP address, then IPv6CP sends the address in its initial Configure-Request as option 3 (IP Address). IPv6CP also sends its address if the peer sends a Configure NAK with ::/0 for option 3 (IP Address), if a valid numbered address is configured for that PPP interface. IPv6CP will not send an unnumbered address to its peer.
A peer may specify its address (referred to as "Client Specified"), or request an address from the router by sending ::/0 for Option 3 in its initial Configure Request. The router obtains this address from the interface. If there is no remote address configured for the interface, and the peer continues to request an address, IPv6CP will fail.
The router automatically adds a static route directed to the PPP interface for the address that is successfully negotiated, allowing data to be routed properly to the dial-in client. When the IPv6CP connection is ended for any reason, this static route is subsequently removed. By default, the prefix length for this route is 128 (hostroute).
IPXCP is specified in RFC 1552. IBM's implementation does not support any IPXCP options.
OSICP is specified in RFC 1377. IBM's implementation of OSICP does not support any options.
Advanced Peer-to-Peer Networking (APPN) High Performance Routing (HPR) control protocol is specified in RFC 2043. No options are negotiated for this control protocol.
Advanced Peer-to-Peer Networking (APPN) Intermediate Session Routing (ISR) control protocol is specified in RFC 2043. No options are negotiated for this control protocol.
See "Using and Configuring Data Encryption" in Using and Configuring Features for information about configuring encryption for a PPP interface.
Virtual Connections (VC) are DIALs dial-in circuits that can be suspended when they become inactive for a predetermined period of time. The ability to suspend the connections can help control your networking costs by saving line charges for DIALs dial-in clients that are not active; instead of keeping the connections active, the system saves information about the session and then closes the call. When the same DIALs dial-in client reconnects to the server, the session information is restored and the connection resumes as if there were no interruption. See Configuring a VC for more information.
You can configure DIALs servers to end VCs that have been suspended for a specified amount of time. You can also manually end a VC at any time. See the set DIALs command and "DIALs Global Monitoring Commands" in Using and Configuring Features for related commands.
Keep the following in mind as you configure VCs:
Configure VCs when you add a DIALs client at the Config> prompt. When you configure the user, you can either use the DIALs dial-in defaults (see the set DIALs command in the Using and Configuring Features) for the maximum suspend time and inactivity timeout, or configure specific values for the particular client. The following example shows the minimum configuration for a VC for DIALs dial-in client "jose."
Config>
Config> add ppp
Enter user name: []? jose
Password:
Enter password again:
Is this a 'DIALs' user? (Yes, No): [Yes§
Type of route? (hostroute, netroute): [hostroute]
IP address: [0.0.0.0]?
Enter hostname for dynamic DNS: []?
Allow Virtual Connections ? (Yes, No): [No] Yes
Use Box Default inactivity timeout value and maximum suspended time? (Yes, No): [Yes] No
User-based Max Suspend Time (hours)
0-48 0=unlimited: [12] ? 10
User-based Inactivity Timeout (seconds)
10-1024: [30] ? 60
Give 'jose' default time allotted ? (Yes, No): [Yes]
Enable callback for 'jose' ? (Yes, No): [No]
Will 'jose' be able to dial-out ? (Yes, No): [No]
PPP user name: jose
User IP address: Interface Default
Netroute Mask: 255.255.255.255
Hostname:
Time alotted: Box Default
Callback type: Not Enabled
Dial-out: Not Enabled
Is information correct? (Yes, No, Quit): [Yes]
User 'jose' has been added
Config>
To display the box-level default values for maximum virtual connections, idle timeout period, and the global default maximum suspend time, use the DIALs config>list vc-parameters command in the DIALs feature. To display these parameters along with the maximum suspend time and inactivity timeout for all virtual connections, use the list all command in the DIALs feature. See "DIALs Global Monitoring Commands" in Using and Configuring Features.